Figure 1:
GLR window state transitions. Dashed-lasso indicates states when windows
are mapped. ``C'' prefixed transitions indicate GLR client initiated
transitions. ``M'' prefixed transitions indicate GLR manager initiated
transitions. Destroy transitions can happen from any state.
The GLR programming interface does not expose its implementation through its programming interface. This enables future GLR implementations to be implemented differently, but the discussion below describes GLR's current implementation.
The client interface is implemented as a shared library that utilizes the Xlib and GLX interfaces. The GLR server is implemented as the combination of an OpenGL/GLX-capable X server and a special X window manager client called glrmanager that enforces the GLR arbitration and scheduling policy. The client library and glrmanager have an agreed protocol for requesting, scheduling, and terminating render intervals. The X server needs no special modifications to support GLR. The client library and glrmanager implementations are quite portable and use no vendor-specific features. Table 2 shows the important underlying routines used to implement various GLR routines.
glrmanager selects substructure notify events on the root window like all X window managers, but unlike standard window managers, glrmanager enforces GLR's policy for render intervals. Figure 1 shows the states that glrmanager will move a client's X window through when a client schedules a render interval.
An interval is scheduled when a client attempts to map a GLR canvas's X window. When glrmanager actually maps the window, the client's render interval begins, indicated to the client by the delivery of a MapNotify event from the X server. To expire a window (i.e., invalidate its frame buffer state), glrmanager simply unmaps the window. When glrEndRenderInterval is called, a GLR client determines if its render interval succeeded based on whether the X window for its canvas received any UnmapNotify events.